1. Field
Embodiments of the invention relate to session management. More specifically, embodiments of the invention relate to transaction based management of session data.
2. Background
For applications, two major design principles exist: they are either stateful or stateless applications. For “stateless applications,” the conversational state can only be found on the front-end (for example, in the browser) and in the persistence layer (normally a database). The middle tier, especially the business logic, does not contain any conversational state. Conversational state is any state that is built up during the conversation (client request processing) with the user and that is kept for longer than one request response cycle. In the discussion before the conversational state of one special user is referred to as “user session” or session. Stateless session beans, as used in Java 2 Enterprise Edition (J2EE), are a good example of a programming model for stateless applications. In “stateful applications,” the state is not limited to special layers but is found on all layers of the application. Notably, the business logic may contain state information that is kept for longer than one request cycle.
One major advantage of stateless applications is that they do not consume memory on the server hosting the application logic for the user sessions across requests, reducing the overall memory consumption. On the other hand, stateless applications require that the necessary data is recreated from the persistence layer for each request. With a stateless middle tier, stateless applications can easily handle load balancing and transaction issues. Each request can be dispatched to another application server, because the request, in conjunction with the persistence layer, contains all information necessary to process it. In addition, rollbacks can be done by performing a rollback on the persistence layer.
In general, stateful applications are easier to design and develop. They trade-in memory on the application server for the time needed to create the session data from the persistence and therefore gain performance advantages in some scenarios. One big drawback of stateful applications is that their state is spread on at least two layers (business logic and persistence) and it may become a burden to keep the state synchronized across different stacks and technologies. Transactional behavior of the session is not supported by the existing session concepts and may become difficult in conjunction with stateful applications.
For clarity, the term, “session” as used herein, refers to data representing an interaction between a client and a server. Another common term referring to the same kind of data is “conversational state” because the session comprises the state that was created on the server due to the conversation between client and server. Different session concepts are used in practice with the HttpSession of Java Servlets as one important example. While the Java Servlet concept for sessions is flat, having no hierarchy inside the session data, the web based SAP WebDynpro sessions can have different scopes building a hierarchy of sessions. The session data is normally associated with one particular user accessing the application on the server via the client.
Sessions are commonly implemented using a token that is transported between the client and the server with each request. The token for example may be a hypertext transfer protocol (HTTP) cookie or the username of the user using the client. A token is used as a key for an associative array (for example, java.util.Map) that contains the session data. The data is typically organized as name/value pairs with the name often restricted to a string and the value allowing nearly any kind of object. Applications can store data in the session by adding references to the data to the session object via a session manager. Modifications to the data inside the session are preformed by the application using references to the objects provided by the session manager. Because of the fact that the application can directly manipulate the objects in the session via the provided references, the session manager is not able to keep a log of all performed modifications.
With this background, the difficulty of stateful session management becomes increasingly clear. Because stateful business applications session data can be found on different layers (e.g., business and persistence) and even spread over different systems and all state must be kept synchronized to maintain the applications integrity, a rollback is necessary to bring the application back to the last known consistent state if a failure or other problem occurs. The direct manipulation of the session data performed by the application makes a rollback impossible with existing session management implementations. Using special types of objects for the session data that provide a change log is normally not an option because the application programmer wants to store business objects inside the session and not special crafted, hard to handle data containers.
Performing a rollback on the persistence layer is relatively simple if a relational database system is used. Performing rollbacks on the business object layer is much more difficult. A stateful application, by definition, does not typically persist its complete state to the database after each request—otherwise it would be a stateless application. As a result, deleting the session state from memory and recreating it from the database will always cause a loss of session information; the session is rolled back to the moment of the last database commit. This loss of information can make it difficult or impossible to restart the session in case of a problem.